home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d20 / zmh124.arc / ZMAILH.TXT < prev   
Text File  |  1991-09-16  |  41KB  |  991 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.                            ZmailH v 1.24
  12.  
  13.                Copyright 1989,90,91 -- PROZ Software
  14.             Written by: Charles Whitlatch and Jason Steck
  15.  
  16.                           User Documentation
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.                           LICENSING
  27.  
  28.     ZmailH and other PROZ Software products are provided "as is".  No
  29. warranty or guarantee is expressed or implied.  This section serves to
  30. absolve PROZ Software and its agents from any responsibility for damages,
  31. liability, or loss of revenue due to the use, misuse, or inability to use
  32. this product. In areas where such limitations on liability are not legal,
  33. this product is not licensed for use.
  34.  
  35.     ZmailH and other PROZ Software products may not be de-compiled, dis-
  36. assembled, patched, or reverse-engineered in any way.  Such actions are a
  37. violation of PROZ Software copyright and will be prosecuted through all
  38. available channels.
  39.  
  40.  
  41.  
  42.                         INTRODUCTION
  43.  
  44. WHAT IS ZmailH?
  45.  
  46.     ZmailH is a integrated netmail/echomail processor designed for use on
  47. Hudson-style message bases in a network environment compatible with the
  48. FidoNet Technical Standards.  At present, "Hudson-style message bases"
  49. include those in use on such systems as QuickBBS, Remote Access, and
  50. SuperBBS.
  51.  
  52.     This manual is intended to assist you in setting up and operating
  53. your ZmailH system.
  54.  
  55.  
  56. REQUIRED EQUIPMENT
  57.  
  58.     ZmailH requires the following equipment and software support to
  59. operate:
  60.   
  61.       1)  PC-DOS/MS-DOS 3.0 or later.
  62.       2)  At least 300k of RAM available.
  63.       3)  An existing Hudson-style message base.
  64.  
  65.       
  66. ZmailH OPERATION
  67.  
  68. Crash Recovery
  69.  
  70.       ZMailH will occasionally write a ZmailH.CRF file in the BBS or
  71. Zzyzx directory. This file is called the Crash Recovery File. It
  72. tells ZMailH the position and file name of the packet file that
  73. was being processed when the system stopped. If this file exists
  74. on the system DO NOT DELETE it ZMailH will delete it when it has
  75. been utilized.
  76.  
  77. ZmailH Exit Errorlevels
  78.  
  79.       When ZmailH has completed its processing or stops for any
  80. reason it will set the errorlevel to one of the following exit
  81. codes.
  82.  
  83.        Errorlevel      Meaning
  84.            0           No Error / Processing performed
  85.            1           DOS Error
  86.            2           Configuration Error
  87.            3           Insufficient Disk Space
  88.            4           Net Mail Tossed/Extracted
  89.            5           Echo Mail Tossed/Extracted
  90.            255         User Abort (^C)
  91.  
  92.       You may wish to trap these errorlevels with a batch file and
  93. process them accordingly.
  94.       If a DOS error is encountered, ZmailH will create or append
  95. to an error log in the current directory. The name of this file
  96. is ZM_ERROR.LOG. This is an ASCII file that contains the state of
  97. ZmailH at the time of the crash. ie. It contains all of the
  98. command line parameters, system generated variables, and other
  99. information. This file should prove useful for determining why
  100. the system crashed.
  101.  
  102.  
  103.       
  104.  
  105.  
  106.                          INSTALLATION
  107.  
  108.  
  109.       ZmailH may be run from any directory. Most often the program
  110. (ZmailH?.EXE) is placed in the BBS directory. The Control file
  111. must be in the directory that is active when ZmailH is run or it
  112. must be specified on the command line (See Command Line Options).
  113.  
  114. INTER-ZONE MAIL SETUP
  115.  
  116.       If ZmailH is used for inter-zone mail there are several adjustments
  117. which must be made to the system configuration. Ommm based systems, such as
  118. Binkley, require that each zone have a separate outbound directory. Non
  119. Ommm based systems, such as SEAdog and FrontDoor, will only require special
  120. outbound directories if they are having ZmailH create and or archive
  121. packets. The default outbound directory, as specified in the Zmail.ctl
  122. file, coincides with the primary address zone.  Alternate zones are handled
  123. in directories that are named as follows: <outbound>.ZZZ where ZZZ is the
  124. zone number in hex and outbound is your default outbound directory.
  125.  
  126.       If ZmailH is used to process echo mail in more than one zone special
  127. care must be taken to ensure that the systems that you are sending the mail
  128. to are also addressing your system correctly.
  129.  
  130. The Key File (<Name>.KEY)
  131.  
  132.       ZmailH uses a key file to ensure that only licensed copies of
  133. the program are being used. The key file must be present in the
  134. ZzyzxPath directory or the BBS directory if the ZzyzxPath is not
  135. specified. The Key file is provided when you register your copy
  136. of the program.  If an appropriate key file is NOT found ZmailH will
  137. require manual intervention to run.
  138.  
  139. The Control File (Zmail.ctl)
  140.  
  141.       ZmailH uses a control file called Zmail.ctl. This file contains
  142. information pertaining to the environment in which ZmailH is to run.  It
  143. must be in the current directory unless specified on the command line. Each
  144. line in the Zmail.ctl file is limited to 255 characters.  Any characters
  145. that follow a semi-colon (;) are considered comments and are ignored. The
  146. Control file provided on the ZmailH disk can be edited or a new Control
  147. file
  148. may be created using any ASCII editor.  If you do not have any other editor
  149. you can use the DOS EDLIN editor (See your DOS manual for more
  150. information). Any command line option may be included in the control file. 
  151.  
  152. Addressing Options
  153.  
  154. NODE
  155.       The first statement in the control file is the NODE 
  156.      statement. This statement specifies what address(es) 
  157.      the BBS uses. The node statement may contain more than 
  158.      one address and there may be more than one node statement 
  159.      in the control    file. The order in which the addresses 
  160.      are listed is important. The first address listed must be 
  161.      the primary address. All AKA's should be listed in priority 
  162.      order. 
  163.  
  164.      Unless explicitly stated otherwise ZmailH will assume that
  165.      the first address is in zone 1. ZmailH uses an extended
  166.      addressing scheme that includes a private network address in
  167.      the address. 
  168.  
  169.       The structure of the Node statement is: 
  170.       NODE [<Zone>:]<Net>/<Node>[.[<PvtNet>/]<Point>]. 
  171.  
  172.       If the node statement was NODE 1:999/102 then ZmailH would
  173.      operate with an address of zone 1, Net 999, and node 102.
  174.      NODE 999/102 would have the same effect. 
  175.  
  176.       If the system also had an address in zone 2 then the zone
  177.      two address would also need to be listed. For example: Node
  178.      999/102 2:333/444 would specify that the BBS has a primary
  179.      address of 1:999/102 and a secondary address of 2:333/444.
  180.      The primary address is used whenever ZmailH is exporting a
  181.      message from the system and there is no other "closer"
  182.      address. If the BBS in the above example were to send a
  183.      message to a board in zone 2 then the address ZmailH would
  184.      use as the origin address would be 2:333/444. if the message
  185.      were to go to zone 3 then ZmailH would use the 1:999/102
  186.      (primary) address. 
  187.  
  188.       The distinction between addresses also carries over to the
  189.      net level. Suppose a BBS had the following node statement in
  190.      the Zmail.ctl file: Node 999/102 90/3 2:333/444. If this
  191.      system were to send a message to 1:90/6 the address that
  192.      ZmailH would use for the origin address would be 1:90/3. If
  193.      the message was going to 2:90/6 then ZmailH would use the
  194.      2:333/444 address. If the message was going to 3:90/6 then
  195.      ZmailH would use the 1:999/102 address.
  196.  
  197.       To specify a private net address to be used as part of a
  198.      point net attached to the system the statement would look
  199.      like: Node 999/102.102102/0. This would inform ZmailH that
  200.      the private net 102102 is also used by node 999/102. ZmailH
  201.      will also automatically forward any mail addressed to
  202.      999/102.xxx to 102102/xxx. ZmailH will automatically map all
  203.      102102/x addresses as necessary. 
  204.  
  205.       All echo mail that is passed into or out of the point
  206.      network will have the seen-by lines stripped down. On import
  207.      they will only contain the addresses within the private net,
  208.      on export they will only contain the addresses outside the
  209.      private net. It should be noted that all 'points' under this
  210.      node should address their echo mail to 102102/0.
  211.  
  212. MAP
  213.       The MAP command allows ZmailH to know of point net addresses
  214.      without having to specify the full address in the AREAS.BBS
  215.      file. 
  216.  
  217.       The structure of this statement is: 
  218.       MAP [<Zone>:][<Net>]/<Node>.<PvtNet>/<Point>. 
  219.  
  220.       If the map statement was MAP 1:999/102.120120/0 this would
  221.      specify that 1:199/102 was the boss node for private net
  222.      120120.
  223.  
  224. Path Options
  225.  
  226. MAILPATH
  227.       The MailPath statement specifies the directory in which net
  228.      mail *.MSG files will be stored. 
  229.  
  230.       This control statement is required and should be of the
  231.      form: MAILPATH [<Drive>:]<Path>.
  232.  
  233.       The MailPath is also used by several other programs. The
  234.      directory that it points to is one of the interface points
  235.      between these programs. Some mailers of the SEAdog type use
  236.      this directory to store messages that list files to be sent.
  237.      Other mailers like Binkley never use this directory
  238.      directly. In a Binkley environment Ommm would bundle the
  239.      messages in the MailPath directory and create packets or
  240.      archived packets. An example of the MailPath statement would
  241.      be: MAILPATH C:\MAILER\MAIL
  242.  
  243. FILESPATH
  244.       FilesPath is the path that points to the directory in which
  245.      your mailer places inbound files. This is where ZmailH will
  246.      find the packets and archived packets that need to be
  247.      processed. This is another interface directory. Both ZmailH
  248.      and your mailer must point to this directory. 
  249.  
  250.       The structure of the FilesPath statement is: 
  251.       FILESPATH [<Drive>:]<Path>. 
  252.  
  253.       An example would look like: FILESPATH C:\MAILER\FILES.
  254.  
  255. OUTBOUNDPATH
  256.       The OutboundPath specifies where the final archived mail
  257.      packets should be stored. On an Ommm system this should be
  258.      the same path that is specified on the Ommm command line as
  259.      the holding path. On SEAdog type systems this may be any
  260.      directory. 
  261.  
  262.       The structure of this statement is: 
  263.       OUTBOUNDPATH [<Drive>:]<Path>. 
  264.  
  265.       An example would look like: OUTBOUNDPATH C:\MAILER\OUTBOUND.
  266. BBSPATH
  267.       The BBSPATH specifies where your BBS software is located. If
  268.      no BBS software is being used on the system then this path
  269.      should point to a directory where ZmailH files should be
  270.      stored. THIS DIRECTORY MUST BE DEFINED. 
  271.  
  272.       The structure of this statement is: 
  273.       BBSPATH [<Drive>:]<Path>. 
  274.  
  275.       An example would look like: BBSPATH E:\BBS.
  276.  
  277. EXPRESSMAIL
  278.       Several off line message reading programs place packeted
  279.      mail in special directories. These systems also create
  280.      messages that have the origin address of the current system.
  281.      If these packets are moved to the netfile directory ZmailH
  282.      will detect them as forgeries (originating on the current
  283.      system) and will toss them to bad messages. To circumvent
  284.      this problem ZmailH uses an ExpressMail directory. The
  285.      expressmail directory is where the offline generated
  286.      messages will be stored.
  287.  
  288.       WARNING: The ExpressMail directory is not checked for
  289.      forgeries, do not allow non-automated access to this
  290.      directory if you are concerned about forgeries.
  291.  
  292.       The structure of this statement is: 
  293.       EXPRESSMAIL [<Drive>:]<Path>. 
  294.  
  295.       An example would look like: EXPRESSMAIL C:\XRS\
  296.  
  297. DUPPATH
  298.       The DupPath is an optional statement that specifies where
  299.      duplicate *.MSG messages should be placed. If the statement
  300.      is omitted no *.MSG files will be created and the processing
  301.      of packets will be much faster. 
  302.  
  303.       The structure of the DupPath statement is: 
  304.       DUPPATH [<Drive>:]<Path>. 
  305.  
  306.       An example would be: DUPPATH E:\MAIL\DUPS.
  307.  
  308. BADMSGS
  309.       The BadMsgs is an optional statement that specifies in what
  310.      directory any bad messages should be stored. This command
  311.      has the same limitations, restrictions as the DupPath
  312.      statement. Bad messages are created when using echo security
  313.      or when mail forwarding and echo forwarding are not enabled.
  314.  
  315.       The structure of this statement is: 
  316.       BADMSGS [<Drive>:]<Path>. 
  317.  
  318.       An example is: BADMSGS E:\MAIL\BAD
  319.  
  320. ARCHIVEPATH
  321.       The ArchivePath is an optional statement that specifies
  322.      where temporary outbound packets should be created and
  323.      updated. If not specified then the outbound path is used.
  324.      The ArchivePath statement allows the sysop to specify a
  325.      drive with extra free space to be used to create the
  326.      outbound packets. Some speed increase may be seen if the
  327.      ArchivePath is on a different drive than the Outbound path.
  328.  
  329.       The structure of this command is: 
  330.       ARCHIVEPATH [<Drive>:]<Path>. 
  331.  
  332.       An example is: ARCHIVEPATH F:\OUT
  333.  
  334.       WARNING: Do NOT use a RAM disk for the Archive Path. Due to
  335.      the nature of the ZmailH disk space detection algorithm it is
  336.      possible to have incomplete packets in the ArchivePath
  337.      between runs. Should the power fail during one of these
  338.      periods the incomplete packets and all messages in them
  339.      would be lost.
  340.  
  341. UNARCPATH
  342.       The UnArcPath is an optional statement that specifies where
  343.      the inbound mail packets are to be unpacked. If it is not
  344.      specified then the FilesPath is used. The ArchivePath
  345.      warning also applies to the UnArcPath statement. 
  346.  
  347.       The structure of the UnArchive Path is: 
  348.       UNARCHIVEPATH [<Drive>:]<Path>. 
  349.  
  350.       An example is: UNARCHIVEPATH F:\IN
  351.  
  352. ZMAILPATH
  353.       The ZMAILPATH is an optional statement that specifies where
  354.      the ZMailH ancillary files will be found. ZmailH will look in
  355.      this directory for the signature and Key files. 
  356.  
  357.       The structure of this statement is: 
  358.       ZMAILPATH [<Drive>:]<Path>.
  359.  
  360.       An example would look like: ZMAILPATH E:\BBS\ZMAIL
  361.  
  362. SWAPPATH
  363.       The SWAPPATH is an optional statement that specifies the 
  364.      directory (preferably a RAMDisk) where ZmailH will write its
  365.      swap file.  The swap file is a file which ZmailH uses to 
  366.      store its current status in while executing external programs
  367.      such as archivers and unarchivers.  Storing this file allows
  368.      ZmailH to temporarily remove itself from memory to provide 
  369.       greater RAM availability for external programs.  If available,
  370.      EMS (Expanded Memory) which conforms to the LIM/EMS 3.2 standard
  371.      or higher will automatically be used instead of the SWAPPATH.
  372.  
  373. Mail Compression Options
  374.  
  375. ARCCOMMAND
  376.       The ArcCommand is used to archive the mail. If ZmailH never
  377.      archives the outbound mail then this line does not need to
  378.      be specified. The archiving function must be specified on
  379.      the command line (See Command Line Options). 
  380.  
  381.       The structure of this command is:
  382.       ARCCOMMAND <Drive>:<Path><Archive Program> <parameters>. 
  383.  
  384.       A full drive and path to the archive program must be
  385.      specified as well as the extension of the archiving program.
  386.      The sysop must also specify the location for the archive and
  387.      file names on the archiving programs command line. To do
  388.      this the sysop places a %A where the archive name should be
  389.      and a %F where the file name to extract should be. 
  390.  
  391.       To use the "standard" ARCA command the control file
  392.      statement would be: ARCCOMMAND C:\UTIL\ARCA.COM %A %F /D
  393.  
  394. UNARCCOMMAND
  395.       The UnArcCommand is the command that is used to unarchive
  396.      inbound archived packets. If ZmailH never unarchives mail
  397.      packets then you do not need to use this line. The
  398.      unarchiving function must be specified on the command line
  399.      (See Command Line Options). 
  400.  
  401.       In order to allow the sysop to use any unpacking program the
  402.      structure of this statement is somewhat complicated:
  403.       UNARCCOMMAND <Drive>:<Path><Unarchive Program> <Parameters>.
  404.  
  405.       This command has the same structure and limitations as the
  406.      ArcCommand.
  407.  
  408.       For example to use the "standard" ARC program in The C:\UTIL
  409.      directory then the line would read: UNARCCOMMAND
  410.      C:\UTIL\ARC.COM -E %A. To use ZOO as the unpacker the line
  411.      would look like: UNARCCOMMAND C:\UTIL\ZOO.EXE -E %A. If the
  412.      sysop has a program called PickARCE.EXE that will determine
  413.      what unpacker to use then the command line might look like:
  414.      UNARCCOMMAND C:\UTIL\PICKARCE.EXE %A. If the sysop had a
  415.      batch file to call the proper unpacking program then the
  416.      command line would look like: UNARCCOMMAND C:\COMMAND.COM /C
  417.      UNPACK.BAT %A
  418.  
  419.       WARNING: Do not use a batch file unless you are certain that
  420.      you will never run short of disk space, and you are certain
  421.      that the batch file works. ZmailH can not determine
  422.      Errorlevels generated by programs run inside batch files.
  423.  
  424.       ZmailH does not have internal facilities to determine what
  425.      type of packer was used. It is the responsibility of the
  426.      sysop to ensure that the proper unpacker is being called.
  427.  
  428.       Note: As of this writing ARC() 5.2 is the FidoNet standard
  429.      for archived mail.
  430.  
  431. System Options
  432.  
  433. OMMM
  434.       The OMMM command tells ZmailH that it is operating in an OMMM
  435.      environment. If you are running SEAdog, Front Door, or any
  436.      other mailer that does not use Ommm than you MUST REMOVE
  437.      this line. 
  438.  
  439.       The format of this statement is: 
  440.       OMMM.
  441.  
  442. FDFIX
  443.       The FDFIX command tells ZMailH that your system uses a FrontDoor
  444.      message editor.  This command is MANDATORY on all systems which
  445.      use the FrontDoor editor in order to work around a bug in the way
  446.      FrontDoor's editor treats message replies.
  447.  
  448. PASSWORDFILE
  449.       The PasswordFile statement is an optional statement that is
  450.      used to point to a password file to be used with packet
  451.      security (see command line options). Passwords may be up to
  452.      8 characters in length and are not case sensitive. 
  453.  
  454.       The structure of the statement is: 
  455.       PASSWORDFILE [<Drive>:]\<Path>\<FileName>[.<Extension>]
  456.  
  457.       The internal structure of the password file is:
  458.            <Address> <Password>
  459.            <Address> <Password>
  460.      
  461.       An example of the file is:
  462.            1:999/123  FRED
  463.            2:123/456  mark
  464.            1:102/214.5 JoesPwd
  465.  
  466. NOSEENBY
  467.       The NoSeenBy statement is an optional statement that
  468.      inhibits the importation of the seen-by lines. Seen-bys are
  469.      still processed and included on messages that are passed
  470.      through the system.
  471.  
  472.       This statement has the structure:
  473.       NOSEENBY
  474.  
  475. NOPATH
  476.       The NoPath statement is an optional statement that inhibits
  477.      the importation of the path lines. Paths are still processed
  478.      and included on messages that are passed through the system.
  479.  
  480.       This statement has the structure:
  481.       NOPATH
  482.  
  483. LOGLEVEL
  484.       When executing ZmailH writes a log in the current directory.
  485.      The loglevel option allows the sysop to set the level of log
  486.      reporting.  Each level will include the information from
  487.      lower log levels as well as the current level. The valid
  488.      levels are from 0 to 6 with the default being 5. The log
  489.      level settings correspond to the following:
  490.  
  491.         Level          Log Entries
  492.            0           Start and Stop times
  493.            1           Dos Errors
  494.            2           Configuration Errors
  495.            3           Insufficient Disk Space
  496.            4           Internally Compensated Errors
  497.            5           Information
  498.            6           Detailed processing information
  499.  
  500.       An example of this command is: 
  501.       LOGLEVEL 3. 
  502.  
  503.       This log level would produce a log that contained only
  504.      references to Dos Errors, Configuration Errors, or
  505.      Insufficient Disk Space errors.
  506.  
  507. RETAIN
  508.       In order to maintain the echo mail "signatures" ZmailH allows
  509.      the sysop to specify how long to keep each signature. Retain
  510.      is an optional command. If it is not used then the default
  511.      retention period is 30 days. When an echo mail message is
  512.      received and processed its signature is stored in a file
  513.      along with the date. If the signature is not seen again for
  514.      the duration of the retention period then the signature is
  515.      removed from the file during the clean operation (See Clean
  516.      Command Line Option).
  517.  
  518.       The retain command has two formats: 
  519.       RETAIN <DAYS> 
  520.       and 
  521.       RETAIN <AREA TAG> <DAYS>. 
  522.  
  523.       The first example changes the default retention from 30 to
  524.      <Days>. 
  525.  
  526.       For example the statement RETAIN 15 would change the default
  527.      retention period from 30 to 15 days.
  528.  
  529.       The second example is used to change the retention period
  530.      for a single conference. For example the statement RETAIN
  531.      SYSOP 25 would change the retention period of signatures in
  532.      the "Sysop" echo from the default to 25 days.
  533.  
  534.       Each retain command must be on a separate line.
  535.  
  536.  
  537. Locking Options
  538.  
  539. RALOCK, QUICKLOCK, SBBSLOCK
  540.       The locking statements are provided for those systems which may 
  541.       be running ZmailH in a multi-line environment using QuickBBS
  542.       2.75 (Gamma-2) or higher, Remote Access 1.00 or higher, or
  543.       SuperBBS 1.12 (Beta-12) or higher.
  544.  
  545.       Use of a locking statement will cause ZmailH to attempt to obtain
  546.       a "lock" on the message base before importing a message into it.
  547.       This locking prevents message base corruption due to conflicts
  548.       in a multi-line environment.  
  549.  
  550.       When attempting to obtain a lock, ZmailH will check to ensure that
  551.       no other application (such as the BBS itself) presently has a 
  552.       lock established on the message base.  If a lock cannot be 
  553.       obtained, ZmailH will re-try for five seconds.  If the lock cannot
  554.       be obtained after that time, ZmailH will save its current status
  555.       (for continuation on the next run) and abort to prevent corruption
  556.       of the message base.
  557.  
  558.       The locking statements are optional.  Systems not running in a 
  559.       multi-line environment should not utilize a locking statement 
  560.       in the Zmail.ctl file.  Systems which DO have locking statements
  561.       must have share.exe loaded or else locking will fail and ZmailH
  562.       will abort.
  563.  
  564.  
  565.  
  566.                      LIST OF CONFERENCES (AREAS.BBS)
  567.  
  568.       In addition to the above files an AREAS.BBS file is also required.
  569. The sysop must create the AREAS.BBS file based on the names of the
  570. conferences that the system is carrying. The AREAS.BBS file must be in the
  571. current directory when ZMailH is run unless specified on the command line
  572. (See Command Line Options). 
  573.  
  574.       The first line of the AREAS.BBS file is a considered a comment line
  575. and is not used. 
  576.  
  577.       The structure of the remaining lines is: 
  578. <Board #> <Tag> [<Zone>:]<Net>/<Node> [[[<Zone>:]<Net>/]<Node>]
  579.  
  580.       The <Board #> is a the number of the board specified in the
  581. configuration program. 
  582.  
  583.       If the echo conference is to be passed through to another system and
  584. you do not wish to keep a copy on your system then the structure is: 
  585. P <Tag> [<Zone>:]<Net>/<Node> [[[<Zone>:]<Net>/]<Node>].
  586.  
  587.       Unlike other echo mail processors ZmailH does not create *.MSG format
  588. messages for pass through areas.
  589.  
  590.       Each area that you receive and/or forward must be listed in the
  591. AREAS.BBS file. There may be more than one line for each area.  However
  592. each line must be a valid AREAS.BBS line.
  593.  
  594.       The zone numbers are optional as long as the systems that you are
  595. passing the echo to are in the same zone as your primary address.  Once a
  596. zone has been specified it does not need to be specified again.  For
  597. example: 
  598. 1 SYSOP 1:99/864 1:99/369 2:333/44 2:543/21 
  599. is the same as 
  600. 1 SYSOP 1:99/864 99/369 2:333/44 543/21
  601.  
  602.       Like the zone numbers net numbers only need to be listed once.  This
  603. means that the above line could be written as:  1 SYSOP 1:99/864 369
  604. 2:333/44 543/21.
  605.  
  606.       The extended addresses, as explained in the node statement, are also
  607. valid. For example: 
  608. 1 SYSOP 1:99/864.864864/2 369 2:333/444 543/21 
  609. Would cause the SYSOP echo to be forwarded to 864864/2, which is understood
  610. to be a point under 99/864.
  611.  
  612.       ZmailH also provides a method to override the command line options
  613. that affect echo mail packeting. If an asterisk '*' is placed before an
  614. address in the areas.bbs file then all messages forwarded to that address
  615. in the current conference will be written to the net mail area as *.MSG
  616. files. This is used primarily to interface with UUNET and other 'external'
  617. networks.
  618. For example: 
  619. UUCP_AREA 99/864 *32/100 
  620. would cause all messages to 32/100 to be tossed as *.MSG files in the net
  621. mail directory while messages to 99/864 will be processed according to the
  622. command line options.
  623.  
  624.       ZmailH will, by default, create "normal" packets, these packets are
  625. neither crash nor hold. When looking for file attaches ZmailH will look for
  626. attaches that have the same flavor as the packets that were created. If
  627. your mail bundling program changes the flavor of the attaches then ZmailH
  628. will not be able to add to the archive. For this reason flavor characters
  629. may proceed the address and follow the asterisk if one exists. The valid
  630. flavor characters are: "C" for Crash, "H" for Hold, and "N" for normal.
  631.  
  632. WARNING: If you find that your system is creating many small packets for a
  633. system verify that the flavor is not being changed and that you have the
  634. correct flavor letters in the AREAS.BBS file.
  635.  
  636.       The complete address entry for the AREAS.BBS file is:
  637. [*][<Flavor>][<Zone>:][<Net>/]<Node>[.[<Pvt Net>/]<Point>]
  638.  
  639.  
  640.                           COMMAND LINE OPTIONS
  641.  
  642.  
  643.       ZmailH is typically run from a batch file. The command line
  644. options listed below control how ZmailH will interact with the
  645. system on any given run. Any command line option can be listed in
  646. the control file. Command line options override control file
  647. statements.  Command line options can be divided into five basic
  648. categories: general, file, packet, echo mail, and net mail.
  649.  
  650. General Commands
  651.  
  652. C (Clean)
  653.       Instructs ZmailH to clean the message signature files. This
  654.      command also causes ZmailH to delete any signature files for
  655.      areas that are no longer carried on the system. it is
  656.      recommended that signature file cleaning be performed once
  657.      per day.
  658.  
  659. S (Scan)
  660.       Instructs ZmailH to scan the bad message area. ZmailH will
  661.      then import or forward any messages that were listed as bad
  662.      messages but are now valid. Such a condition may occur when
  663.      a hub forgets to turn on an echo for a node.
  664.  
  665. T[<FileName>[.<Ext>]] (Traffic)
  666.       Instructs ZmailH to generate an echo mail traffic report. The
  667.      report will contain the average volume of echo mail traffic
  668.      for all of the echo conferences that are carried on or pass
  669.      through the system as well as the total number of signatures
  670.      that are in the file. The report is useful for determining
  671.      what echo areas are dead, if a conference has not been
  672.      turned on by your echo mail hub, and how many messages to
  673.      retain in each of the areas. The report will be appended to
  674.      the file <FileName> if it exists. If <FileName> does not
  675.      exist it will be created. If <FileName> is not specified the
  676.      report will be written to the screen.
  677.  
  678. QB (Quiet Bell)
  679.       Instructs ZmailH to Quiet the Bell. This inhibits any beeping
  680.      that would have otherwise occurred.
  681.  
  682. QS<n> (Quiet Screen)
  683.       Instructs ZmailH to Quiet screen writes. The <n> is the
  684.      equivalent of the log level. The default is 6.
  685.  
  686. File Commands
  687.  
  688. FA<FileName>[.<Ext>]
  689.       Instructs ZmailH to use <FileName>[.<Ext>] instead of the
  690.      standard AREAS.BBS file.
  691.  
  692. FC<FileName>[.<Ext>]
  693.       Instructs ZmailH to use <FileName>[.<Ext>] instead of the
  694.      standard Zmail.ctl file.
  695.  
  696. FL<FileName>[.<Ext>]
  697.       Instructs ZmailH to generate a list of all of the echo areas
  698.      that had messages tossed into them. The list will be
  699.      appended to <FileName>[.<Ext>] if it exists. If
  700.      <FileName>[.<Ext>] does not exist it will be created. If
  701.      <FileName>[.<Ext>] is not specified the ZmailH will display
  702.      the list on the screen.
  703.  
  704. Packet Commands
  705.  
  706. PU (Packet Unarc)
  707.       Instructs ZmailH to unarchive any archived mail it finds in
  708.      the directory specified by the FilesPath control file
  709.      statement. If this option is not specified any archived mail
  710.      will not be processed.
  711.  
  712. PI (Packet Import)
  713.       Instructs ZmailH to process any unarchived mail packets it
  714.      finds in the directories specified by the FilesPath and
  715.      UnArchivePath control file statements. If this command is
  716.      not specified then any mail packets that exist in the
  717.      FilesPath and UnArchivePath directories will not be
  718.      processed.
  719.  
  720. PF (Packet Forward)
  721.       Instructs ZmailH not to unpack any unarchived mail packets
  722.      that are destined for another system. With the PF option
  723.      those packets are simply forwarded. This option only works
  724.      with packets that were created by another ZmailH system and
  725.      it supersedes the PS option listed below.
  726.  
  727. PS (Packet Security)
  728.       Instructs ZmailH not to unpack any unarchived mail packets
  729.      that are not destined for the BBS. ZmailH will rename these
  730.      packets to BADPKT.*. In addition a password may be added to
  731.      the packet. Packet passwords are stored in the file
  732.      specified by the PasswordFile control file statement. At
  733.      this time ZmailH will only check for passwords on packets
  734.      from other ZmailH systems.
  735.  
  736. PA (Packet Archive)
  737.       Instructs ZmailH to archive ALL outbound packets created
  738.      during this run.
  739.  
  740.       WARNING: On Ommm systems, if net mail is packeted and
  741.      archived then no routing may occur.
  742.  
  743. PC (Packet Crash)
  744.       Instructs ZmailH to mark all generated packets as crash mail.
  745.  
  746. PH (Packet Hold)
  747.       Instructs ZmailH to mark all generated packets as hold.
  748.  
  749. Echo Mail Commands
  750.  
  751. EI (Echo Import)
  752.       Instructs ZmailH to import all inbound echo mail messages. If
  753.      this option is not specified then all echo mail messages
  754.      will be tossed, as *.MSG files, into the directory pointed
  755.      to by the MailPath control file statement. Imported echo
  756.      areas must appear in the AREAS.BBS file (or the file
  757.      specified by the FA<FileName>[.<Ext>] option above.). If the
  758.      echo name is not located in the file then the message will
  759.      be tossed, as a *.MSG file, into the directory pointed to by
  760.      the BadMsgs control file statement. If the BadMsgs directory
  761.      is not defined then the message is deleted.
  762.  
  763. ES (Echo Security)
  764.       Instructs ZmailH to verify that the system that forwarded the
  765.      echo mail message to the BBS is listed in the AREAS.BBS file
  766.      (or the file specified by the FA<FileName>[.<Ext>] option
  767.      above). If the message fails the security check then it is
  768.      tossed, as an *.MSG file, into the directory pointed to by
  769.      the BadMsgs control file statement. If the BadMsgs directory
  770.      is not defined then the message is deleted. This option has
  771.      no effect if the EI option is not activated.
  772.  
  773. EF (Echo Forward)
  774.       Instructs ZmailH to forward any echo mail messages that were
  775.      not generated on the BBS. This only occurs when one system
  776.      is using the current system to forward mail to a third
  777.      system. For this option to work the area must be listed in
  778.      the AREAS.BBS or FA<FileName>[.<Ext>] option file, otherwise
  779.      the message will be tossed as a bad message by the EI
  780.      option. If this option is not enabled then the messages are
  781.      tossed, as *.MSG files, to the directory specified by the
  782.      BadMsgs control file statement. If the BadMsgs directory is
  783.      not defined then the messages are deleted. This option has
  784.      no effect if the EI option is not activated.
  785.  
  786. EE (Echo Export)
  787.       Instructs ZmailH to scan the BBS echo messages for any new
  788.      outbound echo mail. The messages are extracted and forwarded
  789.      to the other nodes receiving the echo as specified in the
  790.      AREAS.BBS file (or the file specified by the
  791.      FA<FileName>[.<Ext>] command line option above).
  792.  
  793.       NOTE: Due to ZmailH's one pass algorithm this command should
  794.      only be run after echo mail is entered on the system.
  795.  
  796. EP (Echo Mail Packet)
  797.       Instructs ZmailH to create packet files for all outbound echo
  798.      mail. If this option is NOT used then *.MSG files are
  799.      created in the directory specified by the MailPath control
  800.      file statement.
  801. Net Mail Commands
  802.  
  803. NI (Net mail Import)
  804.       Instructs ZmailH to import all inbound net mail messages. If
  805.      this option is not specified then all net mail messages will
  806.      be tossed, as *.MSG files, into the directory pointed to by
  807.      the MailPath control file statement.
  808.  
  809. NS (Net mail Security)
  810.       Instructs ZmailH not to scan the directory pointed to by the
  811.      MailPath Control file statement. This prevents other systems
  812.      from dropping unauthorized or forged echo mail messages onto
  813.      your system so that it will forward them into the network.
  814.  
  815. NF (Net mail Forward)
  816.       Instructs ZmailH to forward any net mail messages that were
  817.      not generated on the BBS. Regardless of the flavor that the
  818.      message had when it arrived on the system the flavor or the
  819.      forwarded message will be normal to allow for message
  820.      routing. If files are attached to a message that is
  821.      forwarded through the system the file is placed on hold and
  822.      the message is sent along with an appended line informing
  823.      the recipient that the file is on hold. This command must be
  824.      used on host and hub systems that may forward mail for other
  825.      systems. If this option is not enabled then the messages are
  826.      tossed, as *.MSG files, to the directory specified by the
  827.      BadMsgs control file statement. If the BadMsgs directory is
  828.      not defined then the messages are deleted. 
  829.  
  830. NE (Net mail Export)
  831.       Instructs ZmailH to scan the BBS net mail messages for any
  832.      new outbound net mail. The messages are extracted and sent
  833.      to the addressed node.
  834.  
  835. NP (Net mail Packet)
  836.       Instructs ZmailH to create packet files for all outbound net
  837.      mail provided the messages are not marked crash or hold and
  838.      do not have files attached. If this option is NOT used then
  839.      *.MSG files are created in the directory specified by the
  840.      MailPath control file statement.
  841.  
  842.       Note: On non Ommm systems net mail is not usually packeted.
  843.      Also, packeted net mail can not be routed.
  844.  
  845.  
  846.                           COMMAND LINE EXAMPLES
  847.  
  848.       Because ZmailH is so configurable and because it handles three
  849. distinct jobs; mail importing, net mail exporting, and echomail exporting,
  850. it is beyond the scope of this document to give examples of all possible
  851. configuration options. However, included here are some of the more common
  852. command line options. 
  853.  
  854. Import Command Line
  855.  
  856. ZMailH PI PA PU EI EP EF NI NF
  857.       This command line is probably the most common and should
  858.      work for 80% of the systems. It causes ZmailH to unarchive,
  859.      and import any inbound packets, import to the database any
  860.      echo or net mail messages, create packets for any outgoing
  861.      echo mail messages and then archive those packets. It should
  862.      be noted that because the packets are archived they can not
  863.      be routed in an Ommm environment. Any net mail that is not
  864.      destined for the system is placed in the net mail directory
  865.      and is not packeted.
  866.  
  867. Export Command Line
  868.  
  869. ZMailH EE EP PA NS
  870.       This command is probably the most common export command line.
  871.      *.MSG messages in the net mail area will not be scanned and
  872.      packeted with the echo mail. This is useful if net mail was
  873.      previously extracted, an external bundler has not been run,
  874.      and the sysop does not want the net mail to be bundled with
  875.      the echo mail.  Removing the NS entry and replacing it with an
  876.      NP entry would cause netmail to be packeted and archived.
  877.  
  878.  
  879.       WARNING: If net mail messages are packeted and archived they
  880.      can not be routed automatically. The routing program will
  881.      not be able to reroute them. This is of particular
  882.      importance when net mail and echo mail traffic is generated
  883.      at the same time. It is usually better to extract echo mail
  884.      and bundle it prior to extracting the net mail.
  885.  
  886.  
  887.  
  888.                             CUSTOMER SUPPORT
  889.  
  890. Support Echo
  891.  
  892.       The ZMAIL support echo is currently available on many network's
  893. echomail "backbone".  Networks which are known to carry the ZMAIL echomail
  894. conference include FidoNet, MetroNet, NETWork, and AlterNet.  This echo is
  895. intended as the direct line to PROZ Software for questions, answers,
  896. requests and comments regarding ZmailH.
  897.  
  898. Obtaining New Keys
  899.  
  900.       Any registered ZmailH user may receive a new key should the old key
  901. be destroyed (due to a disk error, for example) or should the user's
  902. address change.  To receive a new key, contact the dealer where you
  903. originally purchased your key and inform him/her of your need for a new key
  904. and, if applicable, your new address.  Please include information to assist
  905. the dealer in finding your original purchase record such as your old
  906. address or, if necessary, a copy of the original canceled check.
  907.  
  908. Netmail Support
  909.       
  910.       Netmail support for questions regarding ZmailH can be obtained from:
  911.  
  912.       Jason Steck 
  913.       FidoNet 1:104/424
  914.       MetroNet 200:5000/400
  915.       EggNet 99:910/952
  916.       Network 8:7703/10
  917.  
  918.  
  919.                             COMPRESS UTILITY
  920.  
  921.       The Compress utility (zcmprs?.exe) is used to physically
  922. shrink the size of the signature file. The file cleaning process
  923. will free up space within the file to be used again by the system
  924. however it does not physically shrink the file size. Compress
  925. should not be run during daily maintenance but after an echo has
  926. been removed from the system. The reason Compress should not be
  927. run every day is that if all of the internal space is removed
  928. from the signature file then ZmailH will spend more time expanding
  929. the file, thus causing the system to run slower.
  930.  
  931.       Compress must be run in the directory in which the
  932. ZM_Dups.Sig file exists. It has one optional command line
  933. parameter: /B. The /B will instruct Compress that you want to
  934. delete the backups after compression.
  935.  
  936.       Compress requires that the free space available on the disk
  937. be at least as much as the size of the signature file. Compress
  938. will create a new signature file from the old one and, when
  939. finished, rename the old signature file to ZM_Dups.BAK unless the
  940. /B option is specified
  941.  
  942.       Compress will return one of four errorlevels when it exits.
  943.            Errorlevel        Error
  944.                  0           No Error -- processed normally
  945.                  1           No signature file found
  946.                  2           Unable to create temporary file
  947.                  3           Unable to close new file -- Disk Full?
  948.  
  949.  
  950.  
  951.                        RECOMMENDED UTILITIES
  952.  
  953.      The following utilities are suggested as recommended additions
  954. to a ZmailH implementation:
  955.  
  956. REC (Remote Area Control)
  957.      REC is an automatic areas.bbs maintenance and update utility
  958.      like Areafix.  REC supports the special areas.bbs flavor codes
  959.      included in ZmailH areas.bbs files.
  960.  
  961.      Author: Dan Fitch  (1:104/438@FidoNet)
  962.      Latest Release: 1.20
  963.  
  964. PolyXArc
  965.      PolyXArc is a multiple-format archive extractor program.  This
  966.      utility could be used as the UNARCCOMMAND in Zmail.ctl to easily
  967.      extract many different formats of incoming mail archives.
  968.  
  969.      Author: Jeffrey Nonken  (1:273/715@FidoNet)
  970.      Latest Release: 2.10a
  971.  
  972. TwoPk
  973.      TwoPk allows multiple-format archiving on outbound packets.  This
  974.      utility could be used as the ARCCOMMAND in Zmail.ctl to easily
  975.      allow multiple archiver use on a system-by-system basis for
  976.      outbound mail files.  WARNING: DO NOT USE TWOUPK UTILITY FOR
  977.      EXTRACTION WITH ZmailH 1.20!
  978.  
  979.      Author: Charlie Teufert  (1:269/203@FidoNet)
  980.      Latest Release: 1.14
  981.  
  982. ZMailCfg
  983.      ZMailCfg is a program designed to assist the ZmailH sysop with
  984.      setup and configuration of Zmail.ctl file options.
  985.  
  986.      Author: Joe Lindstrom  (1:134/55@FidoNet)
  987.      Latest Release: 1.20
  988.  
  989.  
  990.      
  991.